I've missed this. Is this PR still valid?

Absolutely. I have rebased and it still succeeds.

I am thinking of re-enabling backend testing in the CI in a folllow-up.

Note that frontend tests are still disabled in PRs, and they will continue to run on master. In that regard, this PR does not change anything.

Note that due to security restrictions, the Sauce Labs addon is not available on pull request

I feel the urge to clarify:

• backend tests are currently NOT run in Travis, this PR does not change anything in that regard
• frontend tests are currently NOT run in PRs, this PR does not change anything in that regard
• the container was never tested, this PR introduces a smoke test.

I am having a look at this now, having a look at TravisCI doc in the meantime :)

If I get it right, the old travis.yml consisted of a single job in the "global scope", run in a VM with nodejs installed, and run tests/frontend/travis/runner.sh.

9ef3342 creates a jobs section for running multiple jobs, and moves the old install and script sections under that, then adds another job that performs the docker build (and succeeds if its exit code is 0).

If I understood this correctly, I am going to proceed to split these two passes.

BTW, in the process I have seen that the jdk dependency was no longer needed (see 86f64a9), and I am now wondering how the frontend test can work at all, given that there is a command that is guaranteed to fail (tests/frontend/travis/sauce_tunnel.sh)

Edit: apparently the failing script was disabled in 2017, and this explains my doubts about tests/frontend/travis/sauce_tunnel.sh. See #2948 (comment). The java dependency can be safely killed.

Note to self: the relevant TravisCI docs for moving under a jobs section is https://docs.travis-ci.com/user/build-matrix/

There are two ways to specify multiple parallel jobs (what we call the build matrix) with a single .travis.yml configuration file:

• combine a language-and-environment dependent set of configuration options to automatically create a matrix of all possible combinations. This is called matrix expansion. For example, the following configuration produces a build matrix that expands to 8 individual (2 * 2 * 2) jobs.
• specify the exact combination of configurations you want in jobs.include. For example, if not all of those combinations are interesting, you can specify just the combinations you want

LGTM

The last commit in this series ("ci: test basic application response of the docker build", 13d9e86) copies & modifies two settings files.

It's Christmas night and this feature merits to be shipped, so let's go with it. As minimum measure, I have rewritten the commit history to make explicit which files were copied and minimize the differences.
The resulting diffs are interesting, and I would like some comments about them, particularly about the second one:

$ diff --unified backend/loadSettings.js container/loadSettings.js (this is easy)

--- backend/loadSettings.js     2019-12-25 00:09:53.368516235 +0100
+++ container/loadSettings.js   2019-12-25 00:09:53.372516247 +0100
@@ -9,13 +9,17 @@
 const fs = require('fs');
 
 function loadSettings(){
-  var settingsStr = fs.readFileSync(__dirname+"/../../settings.json").toString();
+  var settingsStr = fs.readFileSync(__dirname+"/../../settings.json.docker").toString();
   // try to parse the settings
   try {
     if(settingsStr) {
       settingsStr = jsonminify(settingsStr).replace(",]","]").replace(",}","}");
       var settings = JSON.parse(settingsStr);
 
+      // custom settings for running in a container
+      settings.ip = 'localhost';
+      settings.port = '9001';
+
       return settings;
     }
   }catch(e){

diff --unified backend/specs/api/pad.js container/specs/api/pad.js

--- backend/specs/api/pad.js	2019-12-25 00:09:53.368516235 +0100
+++ container/specs/api/pad.js	2019-12-25 00:09:53.372516247 +0100
@@ -47,7 +23,6 @@
   it('finds the version tag', function(done) {
     api.get('/api/')
     .expect(function(res){
-      apiVersion = res.body.currentVersion;
       if (!res.body.currentVersion) throw new Error("No version set in API");
       return;
     })
@@ -57,592 +32,7 @@
 
 describe('Permission', function(){
   it('errors with invalid APIKey', function(done) {
-    // This is broken because Etherpad doesn't handle HTTP codes properly see #2343
-    // If your APIKey is password you deserve to fail all tests anyway
-    var permErrorURL = '/api/'+apiVersion+'/createPad?apikey=password&padID=test';
-    api.get(permErrorURL)
+    api.get('/api/'+apiVersion+'/createPad?apikey=wrong_password&padID=test')
     .expect(401, done)
   });
 })

I will open an issue in Etherpad to remember to get rid of this duplication asap.

Edit: opened #3686, let's continue there.